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3This is in response to tlie appeal brief filed 6/22/2009 appealing from the Office action 
mailed 1/21/2009. 

(1) Real Party in Interest 

A statement identifying by name the real party in interest is contained in the brief. 

(2) Related Appeals and Interferences 

The examiner is not aware of any related appeals, interferences, or judicial 
proceedings which will directly affect or be directly affected by or have a bearing on the 
Board's decision in the pending appeal. 

(3) Status of Claims 

The statement of the status of claims contained in the brief is correct. 

(4) Status of Amendments After Final 

The appellant's statement of the status of amendments after final rejection 
contained in the brief is correct. 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 

(6) Grounds of Rejection to be Reviewed on Appeal 

The appellant's statement of the grounds of rejection to be reviewed on appeal is 
correct. 

(7) Claims Appendix 

The copy of the appealed claims contained in the Appendix to the brief is correct. 

(8) Evidence Relied Upon 

6.507,826 Maners 1-2003 


Application/Control Number: 09/819,462 Page 3 

Art Unit: 3692 

6,882,983 Furphyetal. 4-2005 

"University of New Hampsliire Financial and Administrative Procedures" 
(littp://www.finadmin. unli.edu/pol_proc/cliapter_23/pro23_051 .litml; Issued by 
Computing and Information Services; Issued Date: 01/01/94; retrieved date 9/11/06). 

Gershenfeld, Nancy. "Client-server: What Is It and Are We There Yet?" Online. 
Medford: Mar. 1995. Vol. 19, Iss. 2; pg. 60. 

(9) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 
Claim Rejections - 35 USC § 103 

The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 

obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed 
or described as set forth in section 102 of this title, if the differences between the 
subject matter sought to be patented and the prior art are such that the subject 
matter as a whole would have been obvious at the time the invention was made 
to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was 
made. 

1 . Claims 1 , 20, 21 , 23-28, 30-33, are rejected under 35 U.S.C. 1 03(a) as being 
unpatentable over US 6,507,826 Maners in view of University of New Hampsliire 
Financial and Administrative Procedures, 
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(http://www.finadnnin.unh.edu/pol_proc/chapter_23/pro23_051 .html; Issued by 
Computing and Information Services; Issued Date :0 1/0 1/94; retrieved date 9/11/06) 
hereinafter, Procedures in further view of Furphy et al. (hereinafter Furphy, US Patent 
No.6,882,983). 

Re Claim 1: Maners discloses the invention substantially as claimed including in a 
method for approving and paying an invoice for commodities (Abstract), the steps of: 

receiving, by a front end server from a requestor, a purchase request for goods 
(Col. 2 Lines 6-26), said goods having a designation denoting that the goods are 
receivable which requires a positive confirmation from the requestor to provide 
authorization to pay for the goods, said designation being stored in the front end server 
(Col. 5, lines 40-50; Col. 6 lines 48-67 (dependent invoices can be marked as 
"incomplete", refused, or "operational hold". Fig. 4); an invoice processing system 
comprising the front end server, an application server and a back end server, said back 
end server coupled to the front end server via the application server, said front end 
server comprising a positive confirmation application and a database, said application 
server comprising a positive confirmation bridge. Maners discloses marking said 
commodity as "posted" status which indicates that the invoice has been processed by 
the MicroEDI server and determined valid and submitted to the company accounts 
payable system for payment processing, -see Fig. 4 and col. 6 lines 48-67; 

sending, by the front end server to the back end server, a requisition comprising 
requirements relating to the received purchase request and including the designation; 
generating, by the back end server in response to receiving the requisition sent by the 
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front end server, said purcliase order based on tlie requisition. In fig. 2, Maners disclose 
network server 212, an application server Micro EDI and an SQL Server (included in 
the micro EDI database 214). The application server can process invoices between a 
vendor and a client's accounting system, see Fig. 2 and related text and cols. 4-8; 

said back end server transmitting or delivering the purchase order to a vendor that 
can provide the requested goods; ("This purchase order information is considered part 
of the reference data 218 that is exchanged between the company accounting computer 
system 206 and the Micro EDI database 214 via the local area network 204) col. 7, lines 
25-29; 

after said transmitting or delivering the purchase order to the vendor, said 
application server receiving an invoice from the vendor, said invoice referencing the 
purchase order and requesting payment for the goods; after said application server 
receiving the invoice from the vendor, said positive confirmation bridge marking the 
invoice to indicate that said positive confirmation is required; Col. 5, lines 40-50; Col. 6 
lines 48-67 (dependent invoices can be marked as "incomplete", refused, or 
"operational hold". Fig. 4); 

after said positive confirmation bridge marking the invoice, said back end server 
receiving the invoice from the application server; Maners discloses marking said 
commodity as "posted" status which indicates that the invoice has been processed by 
the MicroEDI server and determined valid and submitted to the company accounts 
payable system for payment processing, -see Fig. 4 and col. 6 lines 48-67; 

responsive to said back end server receiving the invoice from the positive 
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confirmation bridge, said bacl< end server communicating transaction information 
pertaining to tlie invoice to tlie front end server; Maners teaclies an invoice processing 
system including an invoice processing server providing a payment autliorization signal 
to an accounting computer system to initiate processing payment of the invoice in 
response to determining the invoice is authorized for payment .-see Abstract and col. 9 
lines 23-44. 

after said communicating transaction information, said positive confirmation 
application providing notice to the requestor that the invoice has been received and that 
the invoice includes the required positive confirmation; Maners teaches an invoice 
processing system including an invoice processing server providing a payment 
authorization signal to an accounting computer system to initiate processing payment 
of the invoice in response to determining the invoice is authorized for payment .-see 
Abstract and col. 9 lines 23-44. 

after said providing notice to the requestor, said front end server receiving a 
response from the requestor for authorizing or rejecting payment for the goods. 
Maners disclose that the notification to the vendor is via the website -see Fig. 4 "The 
vendor, via the vendor computer system 210, can select to view details of any one of 
the invoices displayed on the grid, add or change information in any of the incomplete 
invoices shown on the grid, or add a new invoice to its grid of invoices. When an 
invoice is in "posted" status, the invoice has been processed by the MicroEDI Server 
202 and determined valid and submitted to the company accounts payable computer 
system 206 for payment processing. When an invoice is in "incomplete" status, the 
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invoice still needs information from the vendor to be ready for validation and posting 
into the company accounts payable computer system 206. An invoice that has been 
assigned a "refused" status has been rejected for payment. And an invoice that is 
assigned "operational hold" status is being held from validation and posting until certain 
information and/or authorization can be obtained by the MicroEDI Server 202. 
Typically, an "operational hold" status for an invoice requires additional information or 
authorization to be entered into the MicroEDI Server 
202 by company personnel. -col. 6 lines 48-67; 

Maners does not specifically disclose if the received response is for authorizing 
payment, then creating an automated receipt transaction file including a goods receipt 
and entering said transaction file into an enterprise resource planning system for 
payment Procedures discloses these limitations on pages 1-11, particularly page 1 , 
underlined text and lines 3-5 wherein Procedures discloses ("Special conditions... are 
also captured on the receipt."), also refer to pages 3, 5, 8, and 10. Procedures 
discloses a three way match system including matching information disclosed on a 
purchase order, invoice, and received goods, and the generating of a receipt. It would 
have been obvious to one of ordinary skill in the art at the time of the invention to modify 
Maners to include the three way matching disclosed by Procedures because this would 
have assured that goods ordered were indeed delivered per purchase order and 
approved by recipient. 

Although Maners discloses "The Micro EDI Database 214 normally stores invoice 
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data 216 and other related reference data 218. The MicroEDI Server 202 can 
receive/transmit invoice data 216 and other related reference data 218 with the 
company's computer system 206 handling the accounting functions for the 
company... can receive/transmit certain invoice data from/to the computer system 210 
at the vendor site." (col. 5 lines 4-21 ) as well as the use of Internet and lntranet(col. 3 
line 41 to col. 5 line 22) , Maners does not explicitly disclose responsive to a response 
entered by said requestor rejecting payment, creating an e-mail notification to accounts 
payable for returning said invoice to said vendor. Furphy however, teaches a 
communication interface and notification of buying company or selling company in 
resolving discrepancies between the invoice and purchase order data. col. 4 lines 18- 
35. and E-mail notification -see Fig. 8 and related text; col. 15 lines 49-65. It would 
have been obvious to one having ordinary skill in the art to include in the invoice 
processing system of Maners and the three way match system of Procedures the 
ability to send an e-mail notification to accounts payable as taught by Furphy since the 
claimed invention is merely a combination of old elements, and in the combination 
each element merely would have performed the same function as it did separately, and 
one of ordinary skill in the art would have recognized that the results of the combination 
were predictable. 

Re claims 20, 21, 23: Maners discloses after said front end server receiving the 
response, said server recoding the response in the database; wherein received 
response is for authorizing payment for the goods; wherein the received response is for 
rejecting payment for the goods, "invoice information received from a vendor computer 
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system is validated in real-time before acceptance for posting in the company's 
accounting computer system. -see col. 5 lines 47-49, "An invoice that has been 
assigned a "refused" status has been rejected for payment." -see col. 6, lines 59-60. 

Re claim 24: Maners discloses providing notice to the requestor to a location 
where positive confirmation can be performed. "And an invoice that is assigned an 
'operational hold' status is being held for validation and posting until certain information 
and/or authorization can be obtained by the Micro EDI server202. Typically, an 
operational hold' status for an invoice requires additional information or authorization be 
entered into the MicroEDI Server 202 by company personnel." Col. 6 lines 60-67; and 
notification of authorization agent in col. 9, also col. 11 claims 5,8. 

Re claims 25, 26: Maners do not specifically disclose wherein the application 
server further comprises a confirmation interface to the database, Furphy however 
teaches a communication interface provided to both the buying and selling companies 
to resolve discrepancies between the purchase order data and the invoice data. Col. 4 
lines 32-35; col. 5 lines 20-28; col. 8 lines 33-41 response via interface. It would have 
been obvious to one having ordinary skill in the art to include in the invoice validation 
system of Maners the ability to validate an invoice via an interface as taught by Furphy 
since the claimed invention is merely a combination of old elements, and in the 
combination each element merely would have performed the same function as it did 
separately, and one of ordinary skill in the art would have recognized that the results of 
the combination were predictable. 
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Claim 27 has similar limitations found in claims 1 and 20 in combination, and 
therefore is rejected by the same art and rationale. 

Claims 28, 30-33 have similar limitations found in claims 21, 23-26 respectively, and 
therefore are rejected by the same art and rationale. 

2. Claims 22 and 29 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Maners, Procedures, and Furphy as applied to claim 21 above, and 
further in view of Gershenfeld, (Gershenfeld, Nancy. "Client-server: What Is It and Are 
We There Yet?" Online. Medford: Mar. 1995. Vol. 19, Iss. 2; pg. 60, 5 pages). 

Re claim 22: Maners discloses "When an invoice is in "posted" status, the 
invoice has been processed by the Micro EDI server 220 and determined valid and 
submitted to the company accounts payable computer system 206 for payment 
processing." Col. 6 lines 52-55; Fig. 4. Maners, Procedures, and Furphy do not 
specifically disclose notifying a back end server via a requisition bridge. It is old and 
well known in the computer networking art that servers, LANS, and networks are 
connected using bridges, also commonly known as routers or gateways as evidenced 
by Gershenfeld p. 2 para. 6 ("LANs now connect many servers... A series of LANs can 
be strung together with bridges...") It would have been obvious to one having ordinary 
skill in the art to include in the invoice and transaction processing methods and systems 
of Maners, Procedures, and Furphy the ability to connect LANS via a bridge as taught 
by Gershenfeld since the claimed invention is merely a combination of old elements, 
and in the combination each element merely would have performed the same function 
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as it did separately, and one of ordinary sl<ill in tlie art would have recognized that the 
results of the combination were predictable. 

Claim 29 has similar limitations found in claim 22, and therefore is rejected by the 
same art and rationale. 

(10) Response to Argument 

In response to the appellant's argument that Maners does not disclose 
three servers. Maners discloses receiving by a front end server from a requestor 
(company 206) a purchase request for goods (company accounting system 206 [front 
end server], sending a request for goods via the MicroEDI server 202 to one of its 
vendors[back end server] 210 . Maners further discloses that the MicroEDI Server 202 
can be networkly coupled via either the Internet or a company's Intranet 222 with 
another computer system 224, 206, for determining authorization of certain invoices for 
payment using a network server, col. 5 lines 1-22 Therefore, it is obvious from the 
teachings of Maners that communications from the MicroEDI server to either the 
company's computer system or vendor's computer system using the Internet is done via 
network servers. Maners discloses an application server (Micro EDI Server-fig. 2 item 
202) that processes invoices between a vendor and a client company's accounting 
system (fig. 2 item 216 and client company's accounting system item 206.) With 
reference to Figure 2 and related text, Maners discloses that the application server can 
process invoices between vendor and a client's accounting system and the purchase 
order information is considered part of the reference data (218, fig. 2) that is exchanged 
between the company accounting computer system 206 and the Micro EDI database. 
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Regarding tlie argument tliat Maners does not disclose generating a purcliase 
request and wlio tlie requestor is, tlie appellant's attention is directed to Col. 2 lines 6- 
67 wherein Maners disclose a typical transaction involves a company 1 creating a 
purchase order, and transmitting the purchase order in EDI format to the vendor 
company 2. The invention disclosed by Maners seeks to more efficiently perform the 
task of entering processing and validating such purchase orders. Furthermore, Maners 
discloses "The first type of invoice is based on orders issued out of a company's 
purchasing computer system which typically is part of the company's accounting 
computer system 206 . "-see col. 5 lines 44-47 

In response to the argument that Maners does not disclose the feature, "said 
goods having a designation denoting that the goods are receivable which requires a 
positive confirmation from the requestor to provide authorization to pay for the goods, 
said designation being stored in the front end server," Maners discloses "When an 
invoice is in ' posted status' , the invoice has been processed by the MicroEDI server202 
and determined valid and submitted to the company accounts payable computer system 
206 for payment processing ." Col. 6 lines 52-55. The purchase order information is 
considered part of the reference data 218 that is exchanged between the company 
accounting computer system 206 and the MicroEDI database 214. col. 7 lines 25-28. 

In response to the argument that Maners in view of Procedure in view of Furphy 
do not disclose "said application server comprising a positive confirmation bridge; said 
positive confirmation bridge marking the invoice to indicate that said positive 
confirmation is required," Maners discloses "When an invoice is in ' posted status' , the 
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invoice lias been processed by tlie MicroEDI server202 and determined valid and 
submitted to tlie company accounts payable computer system 206 for payment 
processing ." Col. 6 lines 52-55; Maners further discloses that the MicroEDI Server 202 
can be networkly coupled via either the Internet or a company's Intranet 222 with 
another computer system 224 for determining authorization of certain invoices for 
payment using a network server .col. 5 lines 1-22. Maners discloses various 
designations of invoice dependent on the status of processing, i.e., posted, incomplete, 
oper hold, refused, ready fax in Fig. 4 and col. 6 lines 48-67. 

Regarding the arguments that Maners fails to disclose "said front end server 
receiving a response from the requestor for authorizing or rejecting payment for the 
goods" and "said front end server recording response in a database." Maners disclose 
requesting authorization from the company to process orphan invoices, and posting the 
orphan invoices to the company's account system col. 8 line 50 to col. 9 line 66. It is 
obvious that in order to "post" an authorized invoice for payment to an accounting 
system, a database is present to capture the data. 

In response to the argument that Maners in view of Procedures, in further view 
of Furphy do not disclose "wherein the received response is for authorizing payment for 
the goods", Maners disclose requesting authorization from the company to process 
orphan invoices, and posting the orphan invoices to the company's account system col. 
8 line 50 to col. 9 line 66. 

Regarding the suggestion that Maners does not disclose wherein the notice 
directs the requestor to a location where the positive confirmation can be performed. 
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Maners discloses seel<ing an autliorizing agent witliin tlie company wlio will provide a 
payment authorization signal. Col. 9 lines 1-65. 

In response to the argument that Maners, Procedures, and Furphy do not 
disclose "wherein the application server further comprises a confirmation interface to the 
database", Furphy teach a communication interface utilized by the buying company and 
selling company for resolving discrepancies between the purchase order data and the 
invoice data, and the interface facilitating communication between parties, providing 
payments, and managing data including keeping records of transactions. Col. 4 lines 
32-35; col. 5 lines 20-28. 

(11) Related Proceeding(s) Appendix 

No decision rendered by a court or the Board is identified by the examiner in the 
Related Appeals and Interferences section of this examiner's answer. 

For the above reasons, it is believed that the rejections should be sustained. 
Respectfully submitted, 
/Elda Milef/ 

Examiner, Art Unit 3692 
Conferees: 
Kambiz Abdi/KA/ 

Supervisory Patent Examiner, Art Unit 3692 


Vincent Millin /vm/ 

Appeals Conference Specialist 
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